Dynamic connection capacity management

ABSTRACT

Systems, methods, and computer program products for the dynamic management of the capacity of connections to a server. One method includes receiving a request to change a first connection to a server and determining active connections to the server. The method also includes determining a corresponding current capacity of each active connection and determining a new capacity for the first connection and the active connections to the server. The method further includes determining that a spare capacity of the server is insufficient for the first connection. The method also includes allocating a capacity to the first connection based on the request. The method further includes adjusting the current capacity of the active connections, including reducing the current capacity of at least a portion of the active connections in proportion to the respective current capacity of the one or more active connections.

BACKGROUND

The present disclosure relates to the management of connections for thecommunication of data between clients and a server and, moreparticularly, to the dynamic management of the capacity of long-livedconnections in response to connection changes.

A data processing system operating as a server receives work from itsclients over connections. Typically, a request for work from a client issent to the server over a connection, the server processes the work andsends a response to the client over the connection. Such a communicationexchange between the client and server for an individual item of workmay be called a “conversation.” In some server applications, such astransaction processing systems, large volumes of work can be processedfor multiple clients concurrently, where each client can send multipleconcurrent requests, some or all of which require processing by theserver. In such applications, each connection may be configured tosupport concurrent conversations with a client over a prolonged periodof time. Thus, each connection is “long-lived” in the sense that itremains active (i.e., in service) for multiple conversations between theclient and server. Furthermore, such long-lived connections oftensupport multiple concurrent requests from the client to the server. Whena connection is added to the server (e.g., upon system start-up/restartor when system changes are made), the new connection can be configuredwith an upper capacity limit indicating the maximum number of concurrentrequests it can support from the client. Conventionally, this capacityfor a connection is configured manually by a system administrator andpersists until the connection is closed.

The ability of a server to carry out work from its clients is limited byits resources, including the processing, memory, and communicationresources available for use by the server. Thus, the server has a finitecapacity to process concurrent requests for its clients. It is difficultfor the system administrator to configure the capacity limit for a newconnection, so as to avoid the risk of server errors (e.g., stalling)due to work overload and/or resource shortages at the server, while, atthe same time, efficiently utilizing resources (e.g., by optimizing thenumber of conversations that can be supported by the connection, and/orthe number of requests processed by the server as a whole, at a giventime).

SUMMARY

Aspects of the present disclosure automatically configure the capacityof connections. In some aspects, the capacity of connections isautomatically determined upon system start-up or restart. In otheraspects, the capacity of connections is dynamically determined inresponse to changes in the connections, such as addition of a connectionor removal of a connection.

According to aspects of the present disclosure, a computer implementedmethod is provided. The method includes receiving a request to change afirst connection to a server and determining active connections to theserver. The method also includes determining a corresponding currentcapacity of each active connection and determining a new capacity forthe first connection and the active connections to the server. Themethod further includes determining that a spare capacity of the serveris insufficient for the first connection. The method also includesallocating a capacity to the first connection based on the request. Themethod further includes adjusting the current capacity of the activeconnections, including reducing the current capacity of at least aportion of the active connections in proportion to the respectivecurrent capacity of the one or more active connections.

Thus, the method dynamically configures the capacity of connections to aserver, in response to changes in connections, without the need formanual intervention. The dynamic configuration takes into account theserver's total capacity and the capacities of the active connections, soas to minimize the risk of overloading the server while optimizing(e.g., maximizing) the capacity and/or utilization of connection andserver resources.

Example implementations of the method determine a new capacity for eachconnection to the server further using an algorithm that provides a fairallocation of the total capacity to each connection based on one or moreparameters associated with the respective client connection. Forinstance, allocation may be based on parameters such as client priority,requested capacity, historical usage, ongoing demand, and the like.

In one aspect, the method dynamically configures the capacity ofconnections to a server, in response to a request to add a newconnection. In some example implementations, the request is a request toadd the first connection to a server and the request specifies arequested capacity for the first connection. The method determines a newcapacity for each connection to the server based on the requestedcapacity for the connection, the total server capacity and the currentcapacities of the active connections.

Thus, the method dynamically configures the capacity of the newconnection and one or more of the existing connections to a server, inresponse to the addition of a connection. Thus, it is possible to addthe new connection, without manual intervention, so as to minimize therisk of server errors while optimizing (e.g., maximizing) the capacityand/or utilization of the new and existing connection and serverresources.

In some example implementations of the above aspect, the method includesdetermining a spare capacity of the server based on the total capacityand the current capacities of the active connections and calculates thenew capacity for one or more connections based on the request and thespare capacity. For example, if the spare capacity of the server issufficient for the new connection, the method allocates a capacity tothe first connection based on the request and leaves the capacity of theactive connections unchanged. If the spare capacity of the server isinsufficient for the first connection, the method allocates a capacityto the first connection based on the request and determines the newcapacity for one or more of the active connections including reducingthe current capacity of one or more of the active connections. In thisway, the allocation of capacity to the new connection is based on theavailability of server resource, so as to prevent server errors, while,as far as possible, meeting the client needs indicated in the request.

Various techniques can be used to reduce the capacity of activeconnections. In some example implementations, the capacity of one ormore active connections is reduced based on an amount of capacityrequired to enable allocation of the capacity to the new connection. Insome example implementations, the capacity of one or more activeconnections is reduced further based on one or more of: current capacityof the respective connection; requested capacity of the respectiveconnection; or renegotiation capability of the respective connection.

In another aspect, the method dynamically configures the capacity ofconnections to a server, in response to the request being a request toremove a connection. In some example implementations, the methodreceives a request to remove a connection and the request identifies theconnection to be removed. The method determines the new capacity for oneor more active connections to the server including determining anincreased capacity for one or more of the active connections.

Thus, the method dynamically configures the capacity of the remainingconnections, in response to the removal of a connection. Thus, it ispossible to remove a connection and reconfigure the remainingconnections, without manual intervention, so as to optimize (e.g.,maximizing) the capacity and/or utilization of the connections andserver resources.

In some example implementations, the method determines an amount ofcapacity of the server for reallocation to the one or more activeconnections based on a current capacity of the connection to be removed.In some example implementations, the method increases the capacity ofone or more remaining active connections based on the determined amountof capacity of the server for reallocation. In the same or other exampleimplementations, the method increases the capacity of one or moreremaining active connections based on one or more of: current capacityof the connection; requested capacity of the connection; orrenegotiation capability of the connection.

In another aspect, the method automatically and dynamically configuresthe capacity of connections during start-up or restart of a server. Insome example implementations, the method includes receiving a request toadd a first connection to a server as part of a start-up procedure ofthe server. The server has a total capacity to process multipleconcurrent requests from one or more clients over respectiveconnections, and connections to the server are configured with acapacity for communicating concurrent client requests. The method alsoincludes determining a capacity for the first connection to the serverbased on the request and the total capacity. The method further includesreceiving one or more requests to add one or more further connections tothe server as part of the start-up procedure. The method also includesdetermining, for each request to add one or more further connections,one or more existing connections to the server and corresponding currentcapacities for each existing connection. The method further includesdetermining, for each request of the one or more requests to add one ormore further connections, a new capacity for the one or more furtherconnections and for each existing connection to the server based on therequest, the total capacity, and the current capacities of the existingconnections. The method also includes determining that a spare capacityof the server is insufficient for the one or more further connectionsand allocating a capacity to the first connection based on each requestof the one or more requests. The method further includes adjusting thecurrent capacity of one or more of the one or more existing connections,including reducing the current capacity of at least a portion of the oneor more existing connections in proportion to the respective currentcapacity of the at least a portion of the one or more existingconnections.

Thus, the method automatically configures the capacity of connections,without manual intervention, as they are added during the start-upprocedure, and dynamically reconfigures them, as necessary, so as tooptimize (e.g., maximize) the capacity and/or utilization of theconnections and server resources.

In some example implementations, the method determines the new capacityfor the one or more second connections and for each existing connectionto the server using an algorithm that provides a fair allocation of thetotal capacity to each of the connections based on parameters associatedwith the respective connection. For instance, allocation may be based onparameters such as client priority, requested capacity, historicalusage, ongoing demand and the like. In the case that the start-upprocedure is a system restart, such parameters may include historicaldata parameters relating to the historical capacity or usage of thecorresponding connection.

In example implementations, in response to a request to add a furtherconnection, the method may use techniques equivalent to the aboveaspect, in which the method dynamically configures the capacity ofconnections to a server, in response to a request to add a newconnection.

In some example implementations of the above aspects, the methodnotifies a client associated with a connection of a determined newcapacity of the connection to the server.

In the same or other example implementations of the above aspects, themethod updates a record of the connections to the server with thedetermined new capacity of connections to the server.

According to another aspect of the present disclosure, a system isprovided. The system comprises a processor associated with a server. Theprocessor is configured to perform the method according to one or moreof the above aspects of the present disclosure.

In example implementations, the system comprises a connection capacitycontroller in communication with a connection manager and a database.The system further comprises a server capacity manager in communicationwith the database. The connection capacity controller is configured toautomatically configure the capacity of connections to the server, inaccordance with aspect of the present disclosure.

According to yet another aspect of the present disclosure, a computerprogram product is provided. The computer program product comprises acomputer readable storage medium having program instructions embodiedtherewith. The program instructions are configured to perform the methodaccording to one or more of the above aspects of the present disclosure.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings included in the present application are incorporated into,and form part of, the specification. They illustrate implementations ofthe present disclosure and, along with the description, serve to explainthe principles of the disclosure. The drawings are only illustrative ofcertain implementations and do not limit the disclosure.

FIG. 1A is a schematic block diagram of a data processing system inaccordance with example implementations of the present disclosure.

FIG. 1B illustrates an example database used by a server in accordancewith example implementations of the present disclosure.

FIG. 2 is a flowchart of an example method for configuring the capacityof connections to a server, in accordance with some implementations ofthe present disclosure.

FIG. 3 is a flowchart of an example method for dynamically configuringthe capacity of connections to a server in response to a request to adda new connection, in accordance with some implementations of the presentdisclosure.

FIG. 4 is a flowchart of an example method for dynamically configuringthe capacity of connections to a server in response to a request toremove an existing connection, in accordance with some implementationsof the present disclosure.

FIG. 5 is a flowchart of an example method for automatically configuringthe capacity of connections during a system start-up or restart, inaccordance with some implementations of the present disclosure.

FIG. 6 is a block diagram of a computing system in accordance withexample implementations of the present disclosure.

While the invention is amenable to various modifications and alternativeforms, specifics thereof have been shown by way of example in thedrawings and will be described in detail. It should be understood,however, that the intention is not to limit the invention to theparticular implementations described. On the contrary, the intention isto cover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention.

DETAILED DESCRIPTION

Servers typically receive and process requests for work from multipleclients over corresponding connections. Some server applications uselong-lived connections. In contrast to short-lived connections, whichare temporarily created for a short time period (e.g., less than asecond) for a single conversation that relates to an individual workitem for the client, long-lived connections remain active for aprolonged time period (e.g., minutes, hours, days, or longer) formultiple, often concurrent, conversations relating to different workitems for a client. Such long-lived connections are typically“stateful,” whereby the server maintains a record of the state of itsactive connections to its clients. Each connection is configured with anupper capacity limit, corresponding to the maximum number of concurrentrequests (i.e., work items or conversations) it can support from theclient. This capacity limit is communicated to the client and stored ina record of the connections to the server. The ability of a server tocarry out work from its clients is limited by the resources availablefor use by the server. In particular, the resources available to theserver limit the number of client requests it can process concurrently.Thus, it is desirable to configure the capacity limit of the connectionsso as to avoid overloading the server, while optimizing the amount ofwork that is concurrently performed for clients using the connectionsand/or the total amount of work that is concurrently performed by theserver.

Conventionally, the capacity limit of a long-lived connection isconfigured manually by a system administrator and persists until theconnection is closed. Manual configuration of a connection can be usedwhen a connection is first added to the server. If the capacity limit ofa connection is configured too low, the amount of work that can bereceived concurrently from the client on a connection may not besufficient to meet the actual demand of the client. This may occur evenin scenarios where spare server capacity is available, for example dueto the removal of another connection from the server after the initialconfiguration of the connection(s). Conversely, if the capacity limit ofa connection is configured too high, the connection may be underutilizedby the client due to lower actual client demand. In consequence, serverresources may not be efficiently utilized by the clients. Accordingly,improved techniques for automatically configuring the capacity limit ofconnections are desirable. Furthermore, improved techniques fordynamically configuring the capacity limit of connections, in responseto changes in the connections such as the addition or removal of aconnection, to more effectively utilize the server resources, isdesirable.

The present disclosure provides methods, systems, and computer programproducts for configuring the capacity limit of one or more clientconnections to a server. In example implementations, the capacity limitof one or more client connections is dynamically configured in responseto changes in the connections to the server. The dynamic configurationof the capacity limit of connections enables more efficient utilizationof server resources without overloading the server, while, as far aspossible, meeting client demand. In example implementations, thecapacity limit of one or more connections is automatically configuredduring a start-up procedure.

In the present disclosure, unless otherwise stated, the term“connection” refers to a long-lived path through a communicationsnetwork between a single client system and a server system, such as atransaction processing system. The term “task” refers to a discrete workitem executing under the control of a client or server system. The term“session” refers to a portion of the connection that is used by a pairof tasks to communicate with each other, one running in the clientsystem and the other in the server system. The term “conversation”refers to the exchange of communications (e.g., messages) between a pairof tasks over a session. The term “capacity” generally refers to theamount of resource(s) available. In example implementations, the term“connection capacity” refers to a maximum number of sessions (i.e.,pairs of client-server tasks or “conversations”) that are supported bythe connection. In some scenarios, the “connection capacity” may also beregarded as the bandwidth of the connection. Similarly, in exampleimplementations, the term “server capacity” refers to a total number ofconcurrent requests that are supported for all of its clients. Unlessotherwise stated, references to changing a connection relate to adding(i.e., opening) or removing (i.e., closing) a connection.

As a person of ordinary skill in the art will appreciate, in someexample implementations, a server comprises a distributed dataprocessing system, called a “server region,” that is configured tohandle service requests (e.g., work items or tasks) from multiple clientdevices over corresponding long-lived connections. An example of such aserver region is a transaction processing system such as a CustomerInformation Control System (CICS®) Transaction Server (TS) for the z/OS®operating system of IBM Corporation. However, the teachings of thepresent disclosure are equally applicable to other server applications.Furthermore, while a particular data processing system may be describedas a “server” or a “client” in a particular scenario, these roles may bedifferent in other scenarios.

FIG. 1A is a schematic block diagram of a data processing system 100 inaccordance with example implementations of the present disclosure. Inparticular, data processing system 100 comprises a server device 110(herein called “server”) arranged for data communication with multipleclient devices 120 (herein called “clients”) over a data communicationsnetwork 135, such as a Transmission Control Protocol/Internet Protocol(TCP/IP) network (e.g., a Local Area Network (LAN), Wide Area network(WAN) or the Internet). For simplicity, the illustrated data processingsystem 100 includes a single network. In other example implementations,clients are connected to the server over multiple networks, which can bedifferent types of network (e.g., implementing different networkprotocols). As a person of ordinary skill in the art will appreciate,the devices and their associated functions in the illustrated system 100are by way of example only.

Network 135 includes connections 140 between the server 110 and eachclient 120. For example, in the context of a TCP/IP network, connectionsmay be established over wired links such as copper or opticalfiber-based cables such as Ethernet, Digital Subscriber Line (DSL),Integrated Services Digital Network (ISDN), Fiber Distributed DataInterface (FDDI) or other type of network-compatible cable, and wirelesslinks may be established by any form of wireless technology, whether nowknown or developed in the future. Each connection 140 is a long-livedcommunication path between the respective client 120 and the server 110.Each connection 140 has communication capacity (i.e., bandwidth) tosupport multiple sessions, so that multiple concurrent conversations(request and response messages for a task) are supported by theconnection.

In the illustrated example implementation, each client 120 can send arequest as a data communication (e.g., request message) over itsconnection 140 to the server 110. In response to receiving andprocessing the request, the server 110 can send a response as a datacommunication (e.g., response message) over the same connection 140 tothe client 120. In example implementations, the requests and responsescan each comprise one or more network packets (e.g., TCP/IP packets) ofstandard or predetermined form, having inter alia a header containingcontrol information and a payload containing data. The header caninclude source and destination addresses and packet length, indicativeof the amount of data contained in the payload (e.g., in bytes).

Server 110 generally includes, or has access to, memory, processing, andcommunications resources for handling client requests. In particular,server 110 utilizes memory and processing resources to store and processdata relating to a client request and the response thereto. In exampleimplementations, server 110 includes a transaction processor 150configured to utilize memory and processing resources for processingmultiple concurrent requests from clients 120. Communications resourcescan include any suitable network interface for enabling communication ofdata (i.e., requests and responses) over connections 140 to and fromclients 120 in accordance with the protocol of network 135.

In the illustrated example implementation, server 110 includes aninput/output (I/O) unit 130. I/O unit 130 includes input queue 132 forqueuing input request messages received from clients 120, and outputqueue 134 for queuing output response messages to be sent to clients120. A transaction processor 150 receives and processes requests fromclients 120 via input queue 132 of I/O unit 130 and sends responses tothe respective clients 120 via output queue 134 of I/O unit 130.

Server 110 further includes a connection manager 160, a connectioncapacity controller 165, a server capacity manager 170, and a database180. Connection manager 160 manages connections 140 for datacommunications to and from the server 110. In particular, connectionmanager 160 handles requests to add and remove connections 140 andmaintains a server connections record 182 (see FIG. 1B) of theconnections 140 in database 180.

Server capacity manager 170 manages the capacity of the server, whichalso can change over time. In example implementations, server capacitymanager 170 determines a total capacity of the server to processconcurrent requests, based on the available memory, communication, andprocessing resources. Server capacity manager 170 stores the totalcapacity of the server 110 in a server capacity record 184 (see FIG. 1B)in database 180.

Connection capacity controller 165 controls the capacity of theconnections, in accordance with the present disclosure. In particular,in example implementations, connection capacity controller 165 receivesan indication of a request to change a connection 140 (e.g., to add orremove a connection 140) from the connection manager 160. In response,connection capacity controller 165 configures the capacity of theconnections 140, based on the request, the total server capacity, andthe capacity of the connections 140 stored in database 180, inaccordance with the methods described below. Thus, connection capacitycontroller 165 is able to automatically configure the capacity ofconnections, for instance as part of a start-up procedure as connectionsare added or dynamically in response to connection changes.

FIG. 1B illustrates an example database 180 in accordance with exampleimplementations of the present disclosure. Database 180 of FIG. 1B canbe the same database 180 of FIG. 1A. Database 180 can containconnections record 182, server capacity record 184, and any other dataused by server 110 of FIG. 1A.

In example implementations, the server connections record 182 includes,for each connection: an identifier (ID); a status (STATUS); a capacity(MAX CAPACITY), and, optionally, a capacity usage (CAPACITY USAGE) suchas a high-water mark for usage of the connection over a time period. Asa person of ordinary skill in the art will appreciate, in other exampleimplementations, the server connections record 182 includes other fixedand/or variable parameters of the connections. The identifier of theconnection uniquely identifies a connection and does not change overtime. For instance, the connection identifier can comprise an identifierof the client. However, the status, capacity, and capacity usage of aconnection can change over time. The status (e.g., active or inactive),is controlled by the connection manager 160, while the capacity andcapacity usage of a connection are controlled by the connection capacitycontroller 165 as described above. While the server connections record182 of FIG. 1B shows a max capacity of 20 for each client, the number 20is not to be read as limiting, nor are implementations of thisdisclosure limited to scenarios where the max capacity of each clientdevice is the same number.

In example implementations, the server capacity record 184 includes: anidentifier (ID); a status (STATUS); a total capacity (TOTAL CAPACITY),and, optionally, a capacity usage (CAPACITY USAGE) such as a high-watermark of capacity usage of the server. As a person of ordinary skill inthe art will appreciate, in other example implementations, the servercapacity record 184 includes other fixed and/or variable parameters ofthe server. Server capacity manager 170 can use any suitable techniquefor determining the total capacity of the server 110. Such techniquesare known in the art and are not described herein.

FIG. 2 is a flowchart of an example method 200 for configuring thecapacity of connections to a server, in accordance with someimplementations of the present disclosure. In particular, the method 200controls the capacity (e.g., bandwidth) of client connections to aserver system, such as a transaction processing system, so as to avoidoverloading the server, while efficiently utilizing the connectionsand/or available server resources, in response to changes in clientconnections. Such changes may include the addition of client connectionsduring system start-up or the addition or removal of client connectionsduring operation of the server. In example implementations, method 200can be performed by the connection capacity controller 165 describedabove with reference to FIG. 1A. In accordance with FIG. 1A and thecomponents depicted therein, the connection capacity controller 165 maycomprise an agent, module, sub-system (or a part thereof) associatedwith the server 110, for managing the capacity of connections 140between the server 110 and its clients 120. In other implementations,method 200 can be performed by a computer, including a server computer,using any components suitable to perform the method. While method 200will be discussed herein as being performed by a capacity controller, itis not limited to such implementations.

Method 200 starts at block 205. At block 210, a capacity controllerreceives a request to change a connection to the server. For example, inone scenario, at block 210 a capacity controller can receive a requestto add a new connection with a particular capacity, for instance for anew client. In another scenario, at block 210 a capacity controller canreceive a request to remove an identified existing connection. Inexample implementations, the request to change one or more connectionsmay be a message, signal, or other indicator received. For example, therequest can be from the connection manager 160 associated with theserver 110 as shown in FIG. 1A, in response to an event for opening orclosing a connection 140. In other example implementations, the requestmay be received from another part of the server, the client device, orotherwise.

At block 220, the capacity controller determines the existing activeconnections and corresponding current capacity. In particular, in theillustrated method, the capacity controller at 220 reviews a record ofconnections to the server in data storage associated with the server toidentify the active connections and their corresponding currentcapacities (i.e., configured capacity limits). In exampleimplementations, the record may correspond to server connections record182 shown in FIG. 1B, comprising for each connection: an identifier(ID); a status (STATUS), and a capacity (MAX CAPACITY). In exampleimplementations in which the server is a transaction processing system,the current capacity can indicate that a maximum number of sessions aresupported by the connection, and, thus, the number of work items fromthe client that can be communicated concurrently using the connection.

At block 230, the capacity controller determines the spare capacity ofthe server. As discussed above, due to limited resources available tothe server, the total capacity of the server to process concurrentclient requests is finite and predetermined. In example implementations,the total capacity of the server may be determined by server capacitymanager 170 and stored in server capacity record 154 as shown in FIGS.1A and 1B. Thus, in scenarios in which the request is to add aconnection, the capacity controller at block 230 calculates the sparecapacity by subtracting the sum of the current capacities of theexisting active connections from the total capacity of the server. Inscenarios in which that the request is to remove a connection, block 230calculates the spare capacity by subtracting the sum of the currentcapacities of the remaining active connections, which remain after theparticular connection is removed, from the total capacity of the server.In example implementations in which the server is a transactionprocessing system, the total capacity of the server can correspond tothe maximum number of tasks that can be handled concurrently by theserver, and the spare capacity thus corresponds to the number of tasksthat the server can handle that are not currently allocated for anactive connection.

At block 240, the capacity controller determines a new capacity for oneor more connections. In scenarios in which the request is to add aconnection, the capacity controller determines a capacity of at leastthe new connection and, optionally, one or more of the existing activeconnections. In scenarios in which the request is to remove aconnection, the capacity controller optionally determines a capacity forone or more of the remaining active connections. In particular, thecapacity controller determines the capacity for each respectiveconnection based on the request, the total server capacity, and thedetermined current capacities of the existing active connections. In theillustrated example implementation, the capacity controller determinesthe capacity for each respective connection based on one or more of: thespare capacity determined in block 230, the request, such as theparticular capacity indicated in the request, and one or more otherparameters according to application requirements. In accordance withexample implementations, any suitable method, procedure, or algorithmfor determining the capacities for connections may be used in block 240.The method may involve other factors or parameters, including thehistorical configured capacity and/or usage of connections, the extentto which negotiation of the capacity of connections with clients ispossible, and other suitable considerations. Examples of other factorsor parameters are described in more detail below.

At block 250, the capacity controller notifies clients associated witheach connection, which have had its capacity changed in block 240, ofits new capacity. At block 260, the capacity controller updates therecord of the connections to the server with the new capacities for theconnection. In scenarios in which a new connection is added, theconnections record is updated to include a data record for the newconnection. The method then ends at block 265.

As a person of ordinary skill in the art will appreciate, it may not benecessary to determine the spare capacity of the server. Thus, in otherexample implementations, block 230 can be omitted. Nevertheless, thecapacity controller at block 240 determines the new capacity of one ormore connections using the server capacity and the capacities of theexisting active connections, for the dynamic configuration of thecapacities of connections based on the requested change.

In accordance with the method 200 of FIG. 2 , the capacity of one ormore active connections is dynamically adjusted in order to improve theefficiency of utilization of server resources, while avoiding the riskof overloading the server and consequent server errors.

FIG. 3 is a flowchart of an example method 300 for dynamicallyconfiguring the capacity of connections to a server in response to arequest to add a connection, in accordance with some implementations ofthe present disclosure. The method 300 of FIG. 3 dynamically controlsthe capacity (e.g., bandwidth) of the new connection and, optionally,existing active connections to a server system, such as a transactionprocessing system, so as to avoid overloading the server, whileefficiently utilizing the connections and/or available server resources.In example implementations, method 300 is performed by the connectioncapacity controller 165 described above with reference to FIG. 1A. Inother implementations, method 300 can be performed by a computer,including a server computer, using any components suitable to performthe method. While method will be discussed herein as being performed bya capacity controller, it is not limited to such implementations.

The method 300 starts at block 305. While FIG. 3 includes a start andend for method 300, it can operate continually during operation of aserver after system start-up by returning to start 305 after reachingend 375. At block 310, the capacity controller receives a request to adda new connection with a particular capacity to the server, for examplefor a new client. In example implementations, the request to add aconnection may be a message, signal, or other indicator, specifying arequested capacity for the new connection, received from another part ofthe server (such as the connection manager 160 of the server 110 of FIG.1A), in response to an event for opening a new connection, or otherwise.

At block 320, the capacity controller determines the active connectionsand corresponding current capacity. In particular, in the illustratedmethod, the capacity controller reviews a record of connections to theserver in data storage associated with the server to identify theexisting active connections and associated current capacity, as in block220 of the method 200 of FIG. 2 .

At block 330, the capacity controller determines the spare capacity ofthe server. In particular, the capacity controller calculates the sparecapacity by subtracting the sum of the current capacities of theexisting active connections from the total capacity of the server. Inexample implementations in which the server is a transaction processingsystem, the total capacity of the server can correspond to a maximumnumber of tasks that can be handled concurrently by the server, and thespare capacity thus corresponds to the number of tasks that the servercan handle concurrently that are not currently allocated for an activeconnection.

At block 335, the capacity controller determines whether the server hassufficient spare capacity to add the connection. In exampleimplementations, the amount of spare capacity sufficient to add theconnection may be the requested capacity, a fixed or variable proportionof the requested capacity, or a minimum capacity for a connection,according to application requirements. In an example implementation, atblock 335 the capacity controller can determine that there is sufficientspare capacity if the determined spare capacity is greater than or equalto the requested capacity. If at block 335 the capacity controllerdetermines that the server does not have sufficient spare capacity toadd the connection, the method proceeds to block 340.

At block 340, the capacity controller determines the capacity for thenew connection and, optionally, for one or more of the existing activeconnections. The capacity controller determines the capacity for eachrespective connection based on the request, the total server capacity,and the determined current capacities for the existing activeconnections. In particular, the capacity controller determines thecapacity for the new connection and one or more of the existing activeconnections based on the requested capacity, the determined sparecapacity, and the determined current capacities of the existing activeconnections. In example implementations, the capacity controller candetermine the capacity for the new connection and one or more of theexisting active connections using a method, technique, or algorithm thatprovides a fair allocation of the total available server capacity toeach of the connections, by taking into account factors or parametersassociated with the connections and/or corresponding clients, such asclient priority, requested capacity, historical connection capacity orusage, ongoing demand, and the like.

In some example implementations, at block 340 the capacity controllerimplements an algorithm comprising the steps: (i) determining a capacityfor the new connection based on a fixed or variable proportion of therequested capacity, (ii) determining whether the spare capacity of theserver is sufficient to provide the capacity and, if not, determiningthe capacity shortfall, and (iii) if there is a capacity shortfall,reducing the capacity of each of the existing active connections inproportion to their current capacities so as to provide the capacityshortfall. Thus, in an example scenario, a server has a total capacityof 100 concurrent tasks and has four active connections, each with acurrent capacity of 20 sessions (i.e., each allowing up to 20 concurrenttasks). A new connection request is received, asking for a capacity of50 sessions. In accordance with the algorithm, the capacity of the newconnection is calculated as 80% of the requested capacity, i.e., 40sessions (step (i)). Since the spare capacity of the server is 20sessions, there is a shortfall of 20 sessions (step (ii)). The algorithmreduces the current capacity of each connection in proportion to itsexisting capacity to obtain the capacity shortfall. Accordingly, thecapacity of each of the four existing active connections is reduced by 5sessions from 20 to 15 sessions (step (iii)).

In other example implementations, the capacity controller at block 340can implement an algorithm that weights the capacities of connectionsbased on parameters associated with the connections. Such parametersinclude: the priorities of the clients/associated connections; thecapacity requested when setting up the connections; historical or actualcapacity or capacity utilization of the connections, and the like. Forexample, the algorithm allocates more capacity (e.g., sessions) toconnections for higher priority clients than those of lower priorityclients. Thus, in the above example, if two of the existing activeconnections have a high priority, then the shortfall may be obtained byonly reducing the capacity of the two, lower priority connections. Inthis case, the algorithm gives the new connection 40 sessions (step(i)), the existing two high priority connections each retain 20sessions, and the existing two lower priority connections have theircapacity reduced from 20 to 10 sessions (step (iii)) to provide theshortfall of 20 sessions (step (ii)). In another example, the algorithmmay only allocate capacity to a connection up to the originallyrequested capacity for the connection. In yet another example, thealgorithm may allocate capacity to connections based on actual orhistorical capacity or capacity utilization. For instance, the algorithmmay consider capacity usage (e.g., high water mark usage), or actual orhistorical usage over a time period, in relation to the currentcapacity, and allocate more capacity to connections having a higherutilization of the capacity. Thus, for example, a connection that has ahigh water mark usage of 90-100% of the current capacity may beallocated more capacity than a connection that has a high water markusage of 10-20% of the current capacity. As a person of ordinary skillin the art will appreciate, other suitable algorithms, methods, ortechniques for determining a fair allocation of server resources torespective new and existing active connections, are possible accordingto application, user, and other requirements. All such suitablealgorithms are contemplated by the present disclosure.

In some example implementations, prior to determining the capacity ofthe new and one or more existing active connections, the capacitycontroller at block 340 considers the negotiation capabilities of theclients associated with the existing active connections. In particular,some clients may communicate requests to the server using communicationprotocols that do not provide for renegotiation of the capacity of aconnection following the initial configuration. In scenarios in whichone or more clients are not capable of renegotiating the capacity oftheir connections, the capacity of the corresponding connections canremain unchanged and these connections can be excluded from thealgorithm to determine the capacities of other existing activeconnections.

In other example implementations or in some scenarios, the capacitycontroller at block 340 can implement an algorithm that allocates theavailable spare capacity to the new connection and leaves the capacitiesof the existing active connections unchanged.

Some example implementations may employ different algorithms accordingto the circumstances, for instance based on parameters associated withthe server (e.g., current state, current loading), parameters associatedwith the client devices (e.g., workload/demand, priority, whether thecapacity can be adjusted by negotiation or otherwise) and/or parametersassociated with the connection (e.g., existing capacity).

At block 350, the capacity controller adds the new connection with thedetermined capacity and, where appropriate, notifies clients of the newcapacity of their corresponding connections, as in block 250 of themethod 200 of FIG. 2 . At block 360, the capacity controller updates therecord of the connections to the server. In particular, the capacitycontroller updates the connections record to identify the new connectionas an active connection and indicate its corresponding capacity in theconnections record, and it updates the capacities for the one or moreexisting connections with new capacities. The method then ends at block375.

Returning to block 335, if it is determined that the server does havesufficient spare capacity to add the connection, for example with therequested capacity, the method proceeds to block 370. At block 370, thecapacity controller adds the new connection with the requested capacity.At block 360, the capacity controller then updates the record of theconnections to the server. In particular, the capacity controllerupdates the connections record to identify the new connection as anactive connection and to indicate its capacity. The method then ends atblock 375.

In example implementations, blocks 330, 335 and 370 of the method 300 ofFIG. 3 may be omitted, and the capacities for the new and one or moreexisting active connections may be determined in block 340 irrespectiveof the existence and/or amount of spare capacity of the server.

FIG. 4 is a flowchart of an example method 400 for dynamicallyconfiguring the capacity of connections to a server in response to arequest to remove an existing connection, in accordance with someimplementations of the present disclosure. The method 400 of FIG. 4dynamically controls the capacity (e.g., bandwidth) of the existingactive connections to a server system, such as a transaction processingsystem, so as to avoid overloading the server, while efficientlyutilizing the connections and/or available server resources. In exampleimplementations, method 400 can be performed by the connection capacitycontroller 165 described above with reference to FIG. 1A. In otherimplementations, method 400 can be performed by a computer, including aserver computer, using any components suitable to perform the method.While method will be discussed herein as being performed by a capacitycontroller, it is not limited to such implementations.

The method 400 starts at block 405. While FIG. 4 includes a start andend for method 400, it can operate continually during operation of aserver after system start-up by returning to start 405 after reachingend 465. At block 410, the capacity controller receives a request toremove an identified connection to the server. In exampleimplementations, the request to remove a connection may be a message,signal, or other indicator, identifying the connection to be removed,for example received from the connection manager 160 of the server 110of FIG. 1A, in response to an event for closing a connection. In otherexample implementations, the request may be received from another partof the server, the client device, or otherwise.

At block 420, the capacity controller determines the existing activeconnections, including the connection to be removed, and correspondingcurrent capacity. In particular, in the illustrated method, the capacitycontroller can review a record of connections to the server in datastorage associated with the server to identify the existing activeconnections and corresponding current capacities, as in block 220 of themethod 200 of FIG. 2 .

At block 430, the capacity controller determines the capacity of theserver for reallocation. In the illustrated method, the capacity of theserver for reallocation can be the amount of capacity made available byremoval of the identified connection. The capacity controller cancalculate the capacity made available (herein called “availablecapacity”) by subtracting the sum of the capacities of the activeconnections remaining, after the identified connection is removed, fromthe total capacity of the server. In example implementations in whichthe server is a transaction processing system, the total capacity of theserver can correspond to a maximum number of tasks that can be handledconcurrently by the server, and the available capacity for reallocationthus corresponds to the number of tasks that the server can handleconcurrently that will not be allocated for an active connection, basedon the current capacities of the existing connections, after theidentified connection is removed.

At block 440, the capacity controller determines the new capacities forone or more of the active connections remaining after the identifiedconnection is removed. At block 440 the capacity controller candetermine new capacities for one or more of the remaining activeconnections based on the request, the determined available capacity, andthe capacities of the existing active connections. In someimplementations, the capacity controller can determine the newcapacities for the one or more remaining active connections additionallybased on one or more of: the originally requested capacity of theconnections, the originally negotiated capacity of the connections, andthe total server capacity. For instance, the capacity controller candetermine a new capacity of a remaining active connection that does notexceed either the capacity assigned to the connection when it was firstadded or the originally requested capacity for the connection. Inexample implementations, the capacity controller can determine the newcapacities for one or more of the remaining active connections using amethod, technique, or algorithm that provides a fair allocation of thetotal server capacity, in particular the available capacity forreallocation following removal of the identified connection, to eachremaining active connection by taking into account factors or parametersassociated with the corresponding clients such as client priority,requested capacity, historical usage, ongoing demand, and the like.

In example implementations, the capacity controller can implement analgorithm that reallocates a fixed or variable proportion of thecapacity made available by removal of the identified connection, to theremaining connections in proportion to their existing currentcapacities. Thus, in an example scenario, a server has a total capacityof 140 concurrent tasks and has five active connections, one with acapacity of 40 sessions (i.e., allowing 40 concurrent tasks) and fourwith a capacity of 20 sessions (i.e., allowing 20 concurrent tasks). Arequest is received identifying one of the connections with a capacityof 20 sessions for removal. In accordance with the algorithm, 100% ofthe available capacity is reallocated to the remaining activeconnections in proportion to their existing capacities. Thus, the 20sessions, made available by removal of the identified connection, arereallocated so that the capacity of the active connection with 40sessions is increased by 8 sessions to 48 sessions and the capacity ofeach of the three other remaining active connections is increased by 4sessions from 20 to 24 sessions. Note that, in this example, the sparecapacity of the server (i.e., 20 sessions) is maintained. In otherexamples, a part or all of the spare capacity (if any) of the server,which is unallocated to active connections before the request isreceived, may be allocated to the remaining connections in block 440.

In example implementations, the capacity controller at block 440 canimplement an algorithm that weights the capacities based on one or moreparameters associated with the connection, as described above inrelation to block 340 of the method 300 of FIG. 3 . Similarly, in someexample implementations, prior to determining the capacities of one ormore of the remaining existing active connections, the capacitycontroller at block 440 can consider the negotiation capabilities of theclients associated with the existing active connections. For clientswithout negotiation capabilities, the capacities of the correspondingconnections can remain unchanged and can be excluded from the algorithmto determine the capacities of the remaining existing active connectionsin block 440, as described above in relation to block 340 of the method300 of FIG. 3 . As a person of ordinary skill in the art willappreciate, other suitable methods, techniques, or algorithms fordetermining a fair allocation of server resources to the remainingactive connections, are possible according to application, user, andother requirements. All such suitable algorithms are contemplated by thepresent disclosure.

At block 450 the capacity controller removes the identified connection.At block 455, the capacity controller notifies clients of the newcapacity of their corresponding connections, where appropriate, as inblock 250 of the method 200 of FIG. 2 . At block 460, the capacitycontroller updates the record of the connections to the server. Inparticular, the capacity controller updates the record to change thestatus of the removed connection from active to inactive (or removesand/or archives the connection record) and updates the capacity of theone or more remaining connections with the new capacity. The method thenends at block 465.

As a person of ordinary skill in the art will appreciate, the methodsdescribed with reference to FIGS. 2, 3, and 4 are merely examples oftechniques for implementing the dynamic reconfiguration of the capacitylimits of connections, in response to connection changes, in accordancewith the present disclosure. Various alternative approaches, and/ormodifications to the described example implementations, are possible,and contemplated by the present disclosure.

FIG. 5 is a flowchart of an example method 500 for automaticallyconfiguring the capacity of connections to a server during systemstart-up or restart, in accordance with some implementations of thepresent disclosure. The method 500 of FIG. 5 controls the capacity(e.g., bandwidth) of connections as they are added to a server system,such as a transaction processing system, so as to avoid overloading theserver, while efficiently utilizing the connections and/or availableserver resources. In example implementations, method 500 is performed bythe connection capacity controller 165 described above with reference toFIG. 1A. In other implementations, method 500 can be performed by acomputer, including a server computer, using any components suitable toperform the method. While method will be discussed herein as beingperformed by a capacity controller, it is not limited to suchimplementations.

The method 500 starts at block 505. In particular, the method 500 startsin response to a system start-up or restart procedure of a server. Atblock 510, the method determines the total capacity of the server. Inexample implementations, the total capacity of the server can bepreconfigured based on the resources available to the server system, andso may be obtained from a server record, such as the server capacityrecord 184 of FIG. 1B. In other example implementations, block 510determines the total capacity server based on the resources available tothe server system, for example as described above in relation to theserver capacity manager 170 of FIG. 1A.

At block 520, the capacity controller receives a request to add a firstconnection with a particular capacity to the server, for example for anew client. In example implementations, the request to add a firstconnection may be a message, signal, or other indicator, specifying arequested capacity for the first connection. The request can be receivedfrom another part of the server, such as the connection manager 160 ofthe server 110 of FIG. 1A, in response to an event for opening a firstconnection, or otherwise. In other example implementations, the requestmay be received from another part of the server, the client device, orotherwise.

At block 530, the capacity controller determines a capacity for thefirst connection based on the requested capacity and the total capacityof the server. In some example implementations, the capacity controllercan determine the capacity to be the requested capacity. In otherexample implementations, the capacity controller can determine thecapacity to be a fixed or varying percentage (e.g., on a sliding scale)of the requested capacity. In some example implementations, the capacitycontroller can use a threshold, such as a defined proportion of thetotal capacity of the server, in determining the capacity. For instance,the threshold may correspond to an amount or proportion of the totalserver capacity that may be allocated to an individual connection. Insome example implementations, the threshold is used to decide on theprocedure to use for determining the capacity. For example, the capacitycontroller can determine that the capacity for the first connection tobe the requested capacity if the requested capacity is less than orequal to the threshold, and can determine the capacity for the firstconnection to be only a proportion of the requested capacity (i.e., lessthan the requested capacity) if the requested capacity is greater thanthe threshold. In other example implementations, the capacity controllercan determine the capacity of the first connection as a minimum ordefault capacity value.

At block 540, the capacity controller adds the first connection to theserver with the determined capacity, notifies the client, and stores thestatus and capacity of the first connection in the record for theconnections to the server, as previously described.

At block 550, the capacity controller determines whether a request toadd a further new connection is received. In example implementations,block 550 may be performed periodically. If no further request to add aconnection is received after a predetermined time period or number ofiterations of block 550, the method ends at block 555. In exampleimplementations, further requests for changes to connections can bethereafter handled in accordance with the methods of one or more ofFIGS. 2, 3, and 4 , as described above. However, if at block 550 thecapacity controller receives a request to add a further new connection,the method proceeds to block 560.

At block 560, the method determines whether the server has sufficientspare capacity to add the connection. In particular, the capacitycontroller determines the spare capacity of the server, as in block 330of the method 300 of FIG. 3 and determines whether there is sufficientspare capacity to add the connection. As described above with referenceto block 335 of the method 300 of FIG. 3 , in example implementations,the amount of spare capacity sufficient to add the connection may be therequested capacity, a fixed or variable proportion of the requestedcapacity, or a minimum capacity for a connection, according toapplication requirements. In an example implementation, the capacitycontroller can determine that there is sufficient spare capacity if thedetermined spare capacity is greater than or equal to the requestedcapacity. If the capacity controller determines that the server does nothave sufficient spare capacity to add the connection (e.g., with therequested capacity), the method proceeds to block 570.

At block 570, the capacity controller determines the capacity of the newconnection and, optionally, one more of the existing activeconnection(s). In particular, the capacity controller can determine thecapacity of connections based on the request, the total server capacity,and the current capacities of the existing active connections. In theillustrated example implementation, the capacity controller candetermine the capacity of the respective connections based on one ormore of: the spare capacity determined as part of block 560, theparticular capacity indicated in the request, and one or more otherparameters according to application requirements. In exampleimplementations, the capacity controller can determine the capacity forthe new connection and one or more existing active connections using amethod, technique, or algorithm that provides a fair allocation of thetotal available server capacity to each of the connections, by takinginto account factors or parameters associated with the correspondingclients such as client priority and requested capacity and the like.Example algorithms are described above in relation to block 340 of themethod of FIG. 3 . Furthermore, in scenarios involving system restart orotherwise, block 570 may take into account historical information aboutthe connections, such as historical configured capacity, historicalusage, historical demand, and the like, as described herein.

In some example implementation, prior to determining the capacity of thenew connection and, optionally, one or more existing active connections,the capacity controller at block 570 can consider the negotiationcapabilities of the clients associated with the existing activeconnection(s). In scenarios in which one or more clients are not capableof renegotiating the capacities of their connections, the capacities ofthe corresponding connections can remain unchanged and can be excludedfrom the algorithm to determine the capacity of any other existingactive connection(s).

At block 575, the capacity controller adds the new connection with thedetermined capacity and, where appropriate, notifies clients of the newcapacity of their corresponding connections, as in block 250 of themethod 200 of FIG. 2 . At block 580, the capacity controller updates therecord of the connections to the server. The capacity controller updatesthe connections record to identify the new connection as an activeconnection in the connections record and updates the capacities for theexisting connections with the new capacities. The method then returns toblock 550 and awaits a further request to add a connection as part ofthe system start-up or restart procedure.

Returning to block 560, if the capacity controller determines that theserver does have sufficient spare capacity to add the connection (e.g.,with the requested capacity), the method proceeds to block 590. At block590, the capacity controller adds the new connection (e.g., with therequested capacity). At block 580 the capacity controller then updatesthe record of the connections to the server. The capacity controllerupdates the connections record to identify the new connection as anactive connection and to indicate its capacity. The method then returnsto block 550 and awaits a further request to add a connection as part ofthe system start-up or restart.

In example implementations, blocks 560 and 590 of the method 500 of FIG.5 may be omitted, and the capacity for the new connection and,optionally, one or more existing active connections may be determined inblock 570 irrespective of the amount of spare capacity of the server.

As indicated above, in some example implementations, the method 500 ofFIG. 5 may utilize historical information about the capacity ofconnections. In particular, historical information about connections maybe stored in an archive of a record of connections to the server, foruse during system restart or otherwise. In example implementationshaving available historical information, block 530 and/or block 570 maydetermine the capacity of a new connection based on historical capacityinformation for the corresponding connection. For example, the capacityof each new connection can initially be set to the most recent capacityfor the corresponding connection, by default. The algorithm can thenverify whether the capacity provides a fair allocation to theconnections, taking into account factors or parameters such ashistorical configured capacity, historical usage, historical demand, andthe like, as described above. Renegotiation may then take place in block570, involving dynamically changing the default capacity of theconnections, as appropriate.

FIG. 6 is a block diagram of a computing system 600 in accordance withexample implementations of the present disclosure. In particular, thecomputing system 600 comprises a server device 610, such as atransaction processing system.

Server device 610 comprises system memory 620, processing unit 630, andinput/output (I/O) unit 640. Server device 610 may include userinterface devices 650 connected to I/O unit 640. User interface devices650 may include one or more of a display (e.g., screen or touchscreen),a printer, a keyboard, a pointing device (e.g., mouse, joystick,touchpad), an audio device (e.g. microphone and/or speaker), and anyother type of user interface device. I/O unit 640 is configured forconnection to a network 660, as described herein, for exchangingmessages with multiple client devices 665. Network 660 may comprise anysuitable wired or wireless data communications network, such as a localarea network (LAN), wide area network (WAN) or the Internet. In someexample implementations, I/O unit 640 is configured for connection tomore than one network, as described above.

System memory 620 comprises one or more processing modules 670, forperforming methods in accordance with the present disclosure. Systemmemory 620 further comprises data records 680, which, in some exampleimplementations, takes the form of a database. Each processing module670 comprises instructions for execution by processing unit 630 forprocessing data and/or instructions received from I/O unit 640 and/orstored in system memory 620.

Processing modules 670 include a connection management (CMM) module 672,a connection capacity control (CCC) module 674, a server capacitymanagement (SCM) module 676, and a transaction processing (TPR) module678. Data records 680 comprise connections record 682 storing datarelating to the status and capacity of the connections to the serverdevice 610. In particular, connections record 682 includes, for eachconnection, a connection identifier, a status indicator, a currentcapacity, and, optionally, a capacity usage such as a high-water mark ofactual capacity usage. Historical data relating to the connectionsrecord 682, such as previous capacity and capacity usage, can beretained in the connections record 682 or in a separate archive. Datarecords 680 further comprise server record 684 storing data relating tothe status and capacity of the server device 610. In particular, serverrecord 648 includes the total capacity of the server device 610.

In example implementations, CMM module 672 is configured to receiverequests to change the connections to the server device 610 (e.g., toadd a new connection or remove an existing connection). CCC module 674is configured to dynamically configure the capacity of the connections,in response to requests for changes in the connections received by CMMmodule 672, in accordance with the present disclosure. In exampleimplementations, CCC module 674 is configured to perform one of more ofthe methods of FIGS. 2, 3, 4, and 5 , as described above. SCM module 676is configured to determine the status and capacity of the server device610 and to update the server record 684 accordingly. CMM module 672, CCCmodule 674, or both can be configured to create and update connectionsrecord 682. TPR module 678 is configured to concurrently process amaximum number of tasks, using available resources of system memory 620and processing unit 630, up to the total capacity of the server device610 stored in server record 684, in response to concurrent requestsreceived over connections from client devices 665 as described herein.

With continuing reference to FIG. 6 , a computer program product 690 isprovided. The computer program product 690 includes computer readablemedia 692 having storage media 694 and program instructions 696 (i.e.,program code) embodied therewith. The program instructions 696 areconfigured to be loaded onto system memory 620 of server device 610 viaI/O unit 640, for example by one of user interface devices 650 or otherdevices connected to network 660. In example implementations, programinstructions 696 can be configured to perform one of more of the methodsdisclosed herein, such as the methods of FIGS. 2, 3, 4 , and 5 asdescribed above.

As the skilled person will appreciate, references to “determining” aparameter or value include not only deriving or calculating the value orparameter, but also include obtaining the value or parameter fromelsewhere, such as from another agent, module, or subsystem, or from alook-up table or other data record in data storage. References to“configuring” a value or parameter include setting a determined value orparameter.

While the present disclosure has been described and illustrated withreference to example implementations, the present disclosure lendsitself to many different variations and modifications not specificallyillustrated herein.

The present disclosure may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer readable storagemedium (or media) having computer readable program instructions thereonfor causing a processor to carry out aspects of the present disclosure.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of a computerreadable storage medium includes the following: a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), a static random access memory (SRAM), a portable compact discread-only memory (CD-ROM), a digital versatile disk (DVD), a memorystick, a floppy disk, a mechanically encoded device such as punch-cardsor raised structures in a groove having instructions recorded thereon,and any suitable combination of the foregoing. A computer readablestorage medium, as used herein, is not to be construed as beingtransitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present disclosure may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some example implementations, electronic circuitryincluding, for example, programmable logic circuitry, field-programmablegate arrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to exampleimplementations of the disclosure. It will be understood that each blockof the flowchart illustrations and/or block diagrams, and combinationsof blocks in the flowchart illustrations and/or block diagrams, can beimplemented by computer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousexample implementations of the present disclosure. In this regard, eachblock in the flowchart or block diagrams may represent a module,segment, or portion of instructions, which comprises one or moreexecutable instructions for implementing the specified logicalfunction(s). In some alternative implementations, the functions noted inthe blocks may occur out of the order noted in the Figures. For example,two blocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts or carry outcombinations of special purpose hardware and computer instructions.

The descriptions of the various implementations of the presentdisclosure have been presented for purposes of illustration, but are notintended to be exhaustive or limited to the implementations disclosed.Many modifications and variations will be apparent to those of ordinaryskill in the art without departing from the scope and spirit of thedescribed implementations. The terminology used herein was chosen toexplain the principles of the implementations, the practical applicationor technical improvement over technologies found in the marketplace, orto enable others of ordinary skill in the art to understand theimplementations disclosed herein.

What is claimed is:
 1. A computer implemented method, comprising:receiving a request to change a first connection to a server;determining one or more active connections to the server; determining acorresponding current capacity of each active connection of the one ormore active connections; determining a new capacity for one or moreconnections of the first connection and the one or more activeconnections to the server; determining that a spare capacity of theserver is insufficient for the first connection; allocating a capacityto the first connection based on the request; and adjusting the currentcapacity of one or more of the one or more active connections,comprising: reducing the current capacity of at least a portion of theone or more active connections in proportion to the respective currentcapacity of the at least a portion of the one or more activeconnections.
 2. The method of claim 1, wherein the determining the newcapacity for the one or more connections to the server comprises usingan algorithm that provides a fair allocation of the total capacity toeach connection based on one or more parameters associated with therespective client connection.
 3. The method of claim 1, wherein: therequest to change the first connection is a request to add the firstconnection to the server; the request specifies a requested capacity forthe first connection; and the determining the new capacity for the oneor more connections of the first connection and the one or more activeconnections to the server is based on the requested capacity for thefirst connection.
 4. The method of claim 3, further comprising:determining a spare capacity of the server based on the total capacityand the current capacities of the one or more active connections.
 5. Themethod of claim 4, wherein the determining the new capacity for one ormore connections of the first connection and the one or more activeconnections to the server further comprises: calculating the newcapacity for each of the one or more connections of the first connectionand the one or more active connections based on the request and thedetermined spare capacity.
 6. The method of claim 4, wherein thedetermining the new capacity for one or more connections of the firstconnection and the one or more active connections to the server furthercomprises: determining that the determined spare capacity of the serveris sufficient for the first connection; and allocating a capacity to thefirst connection based on the request.
 7. The method of claim 1, whereinthe reducing of the current capacity of one or more of the one or moreactive connections is based on an amount of capacity required to enableallocation of the capacity to the first connection.
 8. The method ofclaim 7, wherein the reducing of the current capacity of one or more ofthe one or more active connections is further based on one or moreparameters selected from the group consisting of: current capacity ofthe respective connection; requested capacity of the respectiveconnection, and renegotiation capability of the respective connection.9. The method of claim 1, wherein: the request to change the firstconnection is a request to remove the first connection; the requestidentifies the first connection to be removed; and the determining thenew capacity for one or more connections of the first connection and theone or more active connections to the server further comprisesdetermining an increased capacity for one or more of the one or moreactive connections.
 10. The method of claim 9, further comprising:determining an amount of capacity of the server for reallocation to theone or more active connections based on a current capacity of the firstconnection.
 11. The method of claim 10, wherein the determining anincreased capacity for one or more of the one or more active connectionsis based on the determined amount of capacity of the server forreallocation.
 12. The method of claim 11, wherein the determining anincreased capacity for one or more of the one or more active connectionsis further based on one or more parameters selected from the groupconsisting of: current capacity of the respective connection; originallynegotiated capacity of the respective connection, originally requestedcapacity of the respective connection, and renegotiation capability ofthe respective connection.
 13. The method of claim 1, furthercomprising: notifying one or more clients associated with the newcapacity.
 14. The method of claim 1, further comprising: updating arecord of connections to the server with the new capacity.
 15. A system,comprising: a processor associated with a server, wherein the processoris configured to: receive a request to change a first connection to aserver; determine one or more active connections to the server;determine a new capacity for one or more connections of the firstconnection and the one or more active connections to the server;determine that a spare capacity of the server is insufficient for thefirst connection; allocate a capacity to the first connection based onthe request; and adjust the current capacity of one or more of the oneor more active connections, comprising: reduce the current capacity ofat least a portion of the one or more active connections in proportionto the respective current capacity of the at least a portion of the oneor more active connections.
 16. The system of claim 15, wherein theprocessor is further configured to: determine the new capacity for oneor more connections to the server further comprises through an algorithmthat provides a fair allocation of the total capacity to each connectionbased on one or more parameters associated with the respective clientconnection.
 17. The system of claim 15, wherein: the request to changethe first connection is a request to add the first connection to theserver; the request specifies a requested capacity for the firstconnection; and the processor is further configured to: determine thenew capacity for the one or more connections of the first connection andthe one or more active connections to the server further based on therequested capacity for the first connection.
 18. The system of claim 15,wherein: the request to change the first connection is a request toremove the first connection; the request identifies the first connectionto be removed; and the processor is further configured to: determine thenew capacity for the one or more connections of the first connection andthe one or more active connections to the server through determining anincreased capacity for one or more of the one or more activeconnections.
 19. A computer program product comprising a computerreadable storage medium having program instructions embodied therewith,wherein the program instructions executable by a processor to cause theprocessor to: receive a request to change a first connection to aserver; determine one or more active connections to the server;determine a new capacity for one or more connections of the firstconnection and the one or more active connections to the server;determine that a spare capacity of the server is insufficient for thefirst connection; allocate a capacity to the first connection based onthe request; and adjust the current capacity of one or more of the oneor more active connections, comprising: reduce the current capacity ofat least a portion of the one or more active connections in proportionto the respective current capacity of the at least a portion of the oneor more active connections.
 20. A computer implemented method,comprising: receiving a request to add a first connection to a server aspart of a start-up procedure of the server; determining a capacity forthe first connection to the server; receiving one or more requests toadd one or more further connections to the server as part of thestart-up procedure; determining, for each request to add one or morefurther connections, one or more existing connections to the server andcorresponding current capacities for each existing connection;determining, for each request of the one or more requests to add one ormore further connections, a new capacity for the one or more furtherconnections and for each existing connection to the server; determiningthat a spare capacity of the server is insufficient for the one or morefurther connections; allocating a capacity to the first connection basedon each request of the one or more requests; and adjusting the currentcapacity of one or more of the one or more existing connections,comprising: reducing the current capacity of at least a portion of theone or more existing connections in proportion to the respective currentcapacity of the at least a portion of the one or more existingconnections.
 21. The method of claim 20, wherein the determining the newcapacity for the one or more further connections and for each existingconnection to the server uses an algorithm that provides a fairallocation of the total capacity to each of the connections based on oneor more parameters associated with the respective connection.
 22. Themethod of claim 20, wherein: the one or more requests to add one or morefurther connections to the server specify a requested capacity for theone or more further connections; and the determining the new capacityfor the one or more further connections and for each existing connectionto the server is based on the requested capacity for the one or morefurther connections, the total capacity, and the current capacities ofthe existing connections.
 23. The method of claim 22, furthercomprising: determining a spare capacity of the server based on thetotal capacity and the current capacities of the existing connections;and calculating the new capacity for the one or more further connectionsand for each existing connection based on the request and the sparecapacity.
 24. The method of claim 23, wherein the determining the newcapacity for one or more further connections and for each existingconnection to the server further comprises: calculating the new capacityfor each of the existing connections based on the one or more requestsand the determined spare capacity; determining that the determined sparecapacity of the server is sufficient for the one or more requests; andallocating a capacity to the first connection based on the one or morerequests.
 25. The method of claim 24, wherein reducing the currentcapacity of one or more existing connections is based on an amount ofcapacity required to enable allocation of capacity to the one or morefurther connections and one or more parameters selected from the groupconsisting of: current capacity of the respective connection; requestedcapacity of the respective connection, and renegotiation capability ofthe respective connection.